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DETAILED ACTION 

L This action is responsive to communications: Amendment C filed 1 1/3/2003. 

2. Claims 1-47 are pending in the case. Claims 1,5, 14, 20, 31, 37, 41, and 44 are 
independent claims. 

3. The objection to the specification has been withdrawn in view of Applicant's 
amendment. 

4. The rejections of Claims 5-7, 14-19, 31-36, and 44-47 under § 1 12 have been withdrawn 
in view of the Applicant's amendment, and comments regarding claim 14. 

5. Claims 1-47 remain rejected in view of the previously cited art. 

Claim Rejections - 35 USC §103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentabihty shall not be negatived by the 
manner in which the invention was made. 

7. Claim 37 remains rejected under 35 U.S.C. 103(a) as being unpatentable over Bayeh 
et al (USPN 6012098—2/23/1998) and further in view of "Internet Explorer 5 and XML" 
by Charles Heinemann (published 11/4/1998). 

Regarding independent claim 37, Bayeh discloses gathering the data (col. 10, lines 46-58) with 
a servlet, which is an object, which inherently must be called. Bayeh also teaches formatting 
data into an XML syntax (col 11, 11. 1-2). Bayeh discloses emitting formatted data (col. 1 1, 11. 
20-24). However Bayeh does not teach formatting with the object that was passed the data. 
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Rather Bayeh teaches that first it is formatted within the same object that gathered the data. It 
would have been obvious to one of ordinary skill in the art at the time of the invention to call 
another object to format the data, due to make the programming more modular in nature, which 
would in turn allow for greater flexibility in formats (col 2, 1. 59 - col. 3, 1. 29), as well as allow 
increasing throughput (col. 8, 11. 35-63). 

Bayeh also teaches that multiple servlets may call multiple servlets (col. 8, 11. 43-45). Bayeh 
does not expKcitly disclose to a pre-defined order of calls. It would have been obvious to one of 
ordinary skill in the art at the time of the invention to call these servlets in a predefined order, as 
the XML documents would be in a predefined linear order. 

Bayeh does not teach sending XML but rather HTML because browsers at the time of Bayeh 
"expect[ed] to receive data that had been formatted with HTML." (Col 1 1, 11. 35-43) 
Heinemann teaches that browsers at the time of the invention expected to receive XML data (p. 
1,1^^ para, and p. 5, "Direct Viewing"). It would have been obvious to one of ordinary skill in 
the art at the time of the invention to combine Heinemann with Bayeh and send the unformatted 
XML as it would allow the client computer to use the capabilities of XML such as validation 
(Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
8. Claims 1-7, 10-11, 13-14, 16-17, 19, 31-32, 34-35, and 38 remain rejected under 35 
U.S.C. 103(a) as being unpatentable over Bayeh, and further in view of Heinemann, and 
further in view of "XML Fragment Interchange, W3C Working Draft" (published 
3/3/1999) hereinafter W3C. 

Regarding independent claim 1, Bayeh discloses processing and fomiatting results as XML 
(FIG 5, step 260). Preparing is broadly interpreted by the examiner to be equivalent to 
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formatting and processing. Bayeh does not teach sending XML but rather HTML because 
browsers at the time of Bayeh "expect[ed] to receive data that had been formatted with HTML." 
(Col 1 1, 11. 35-43) Heinemann teaches that browsers at the time of the invention expected to 
receive XML data (p. 1,1'^ para, and p. 5, "Direct Viewing"). It would have been obvious to one 
of ordinary skill in the art at the time of the invention to combine Heinemann with Bayeh and 
send the unformatted XML as it would allow the client computer to use the capabilities of XML 
such as validation (Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
Neither Bayeh nor Heinemann disclose dealing with the XML in portions. W3C discloses a 
method of dividing XML in to fragments (portions) as well as sending them (Abstract). It would 
have been obvious to combine Bayeh, Heinemann and W3C in order to deal with portions of 
XML so that if the user wants a particular section, he does need to receive them all (W3C, p. 3, 
"Overview", 2"^ para.). 

Neither of the sources discloses repeating the steps until the document is sent, however W3C 
does teach that the portions may be used to reassemble the document (p. 3, Overview para. 2, last 
line.) Therefore it would have been obvious to repeat the steps until the document is sent so that 
the parts could be reassembled (p. 3, Overview para. 2, last line). 

Regarding dependent claim 2, Bayeh discloses gathering the data (col. 10, lines 46-58). Bayeh 
discloses calling an object (servlet) and passing it the data (col. 1 1, 11. 20-24). Bayeh also 
teaches formatting data into XML syntax (col 1 1, 11. 1-2). However Bayeh does not teach 
formatting with the object that was passed the data Rather Bayeh teaches that first it is 
formatted within the same object that gathered the data. It would have been obvious to one of 
ordinary skill in the art at the time of the invention to call another object to format the data, due 
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to make the programming more modular in nature, which would in turn allow for greater 
flexibility in formats (col. 2, 1. 59 - col. 3, 1. 29), as well as allow increasing throughput (col 8, 
11. 35-63). 

Regarding dependent claim 3, Bayeh teaches a gathering object to gather data (col. 10, lines 
46-58). 

Regarding dependent claim 4, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Regarding independent claim 5, Bayeh discloses receiving a request (col 10, lines 19-25). 
Bayeh discloses processing and formatting results as XML (FIG 5, step 260). Preparing is 
broadly interpreted by the examiner to be equivalent to formatting and processing. Bayeh does 
not teach sending XML but rather HTML because browsers at the time of Bayeh "expect[ed] to 
receive data that had been formatted with HTML." (Col 1 1, 11. 35-43) Heinemann teaches that 
browsers at the time of the invention expected to receive XML data (p. 1,1^^ para, and p. 5, 
"Direct Viewing"). It would have been obvious to one of ordinary skill in the art at the time of 
the invention to combine Heinemann with Bayeh and send the unformatted XML as it would 
allow the client computer to use the capabilities of XML such as validation (Heinemann, p. 2), 
DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 

Neither Bayeh nor Heinemann disclose dealing with the XML in portions. W3C discloses 
sending a method of dividing XML in to fragments (portions) as well as sending them (Abstract). 
It would have been obvious to combine Bayeh, Heinemann and W3C in order to deal with 
portions of XML so that if the user wants a particular section, he does need to receive them all 
(W3C, p. 3, "Overview", 2"^^ para.). 
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Regarding dependent claim 6, neither of the sources discloses repeating the steps until the 
document is sent, however W3C does teach that the portions may be used to reassemble the 
document (p. 3, Overview para. 2, last line). Therefore it would have been obvious to repeat the 
steps until the document is sent so that the parts could be reassembled (p. 3, Overview para. 2, 
last line). 

Regarding dependent claim 7, neither of the sources discloses repeating the steps until the 
document is sent, however W3C does teach that the portions may be used to reassemble the 
document (p. 3, Overview para. 2, last line). Therefore it would have been obvious to repeat the 
steps until the document is sent so that the parts could be reassembled. 

While none of the sources disclose sending portions in order, it would have been obvious to do 
so, in order to reduce the complexity, when the data is reassembled (p. 3, Overview para. 2, last 
line). 

Regarding dependent claim 10, Bayeh discloses gathering the data (col. 10, lines 46-58), 
inherently with some kind of mechanism. Bayeh also teaches formatting data into an XML 
syntax (col. 1, 11 1-2), inherently with some kind of mechanism. 

Regarding dependent claim 11, as Bayeh, W3C, and Heinemann discloses sending the 
response as described in claim 5 above, there was inherently a mechanism to do so. 
Regarding dependent claims 13, the program of claim 13 is the program for carrying out the 
method of claim 5 and is rejected under the same rationale. 

Regarding independent claim 14, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Bayeh discloses gathering the data (col. 10, lines 46-58) that is to appear in response. Bayeh also 
teaches formatting data into an XML syntax (col. 1 1, 11. 1-2). Bayeh discloses emitting 
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formatted data (col. 1 1, 11. 20-24). However Bayeh does not teach formatting with the object that 
was passed the data. Rather Bayeh teaches that first it is formatted within the same object that 
gathered the data. It would have been obvious to one of ordinary skill in the art at the time of the 
invention to call another object to format the data, due to make the programming more modular 
in nature, which would in turn allow for greater flexibility in formats (col. 2, 1. 59 - col. 3, 1, 29), 
as well as allow increasing throughput (col. 8, 11 35-63). 

Bayeh does not teach sending XML but rather HTML because browsers at the time of Bayeh 
"expect[ed] to receive data that had been formatted with HTML." (Col. 1 1, 11. 35-43) 
Heinemann teaches that browsers at the time of the invention expected to receive XML data (p. 
1,1^' para, and p. 5, "Direct Viewing"). It would have been obvious to one of ordinary skill in 
the art at the time of the invention to combine Heinemann with Bayeh and send the unformatted 
XML as it would allow the client computer to use the capabilities of XML such as validation 
(Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
As Bayeh makes no mention of building a hierarchical tree, the Office interprets its absence to 
mean that it also emits data "in a manner in which" a tree would not have to be built. However, 
W3C discloses sending a method of dividing XML in to fragments (portions) as well as sending 
them (Abstract). As the pieces were sent in portions, none of portions would be the full XML 
response; therefore there would be no need to build the hierarchical tree that represents the fiill 
XML response. It would have been obvious to combine Bayeh, Heinemann and W3C in order to 
deal with portions of XML so that if the user wants a particular section, he does need to receive 
them all (W3C, p. 3, "Overview", 2^^ para.). 
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Regarding dependent claim 16, Bayeh does teach calling an object as described in claim 14 
above. W3C teaches splitting a document into parts as described in claim 14 above. Bayeh, 
W3C, and Heinemann do not disclose calling an object multiple times. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to call the objects multiple 
times thereby process multiple parts of the document so that at the client they could be 
reassembled (W3C, p. 3, Overview para. 2, last line). 

Regarding dependent claim 17, Bayeh does teach calling an object as described in claim 14 
above. W3C teaches splitting a document into parts as described in claim 14 above. Bayeh, 
W3C, and Heinemann do not disclose calling an object multiple times. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to call the objects multiple 
times thereby process multiple parts of the document so that at the client they could be 
reassembled (W3C, p. 3, Overview para. 2, last line). 

While none of the sources disclose sending portions in order, it would have been obvious to do 
so, in order to reduce the complexity, when the data is reassembled (p. 3, Overview para. 2, last 
line). 

Regarding dependent claim 19, the program of claim 19 is the program for carrying out the 
method of claim 14 and is rejected under the same rationale. 

Regarding independent claim 31, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Inherently, Bayeh has a mechanism for dealing with such a request. Bayeh discloses processing 
and formatting results as XML (FIG 5, step 260). Preparing is broadly interpreted by the 
examiner to be equivalent to formatting and processing. Inherently Bayeh has a mechanism for 
preparing, that is also couple to request-receiving mechanism as it prepares the response to the 
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said request handled by said request-receiving mechanism. Bayeh does not teach sending XML 
but rather HTML because browsers at the time of Bayeh "expect[ed] to receive data that had 
been formatted with HTML." (Col. 1 1, 11. 35-43) Inherently there was a mechanism for sending. 
Heinemann teaches that browsers at the time of the invention expected to receive XML data (p. 
1, 1^^ para, and p. 5, "Direct Viewing"). It would have been obvious to one of ordinary skill in 
the art at the time of the invention to combine Heinemann with Bayeh and send the XML as it 
would allow the cUent computer to use the capabilities of XML such as validation (Heinemann, 
p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 

Neither Bayeh nor Heinemann disclose dealing with the XML in portions. W3C discloses 
sending a method of dividing XML in to fragments (portions) that constitute less the entirety of 
the documents, as well as sending them (Abstract and p. 5, para. 1). It would have been obvious 
to combine Bayeh, Heinemann and W3C in order to deal with portions of XML so that if the 
user wants a particular section, he does need to receive them all (W3C, p. 3, "Overview", 2^^ 
para.). 

Regarding dependent claim 32, neither of the sources discloses repeating the steps until the 
document is sent, however W3C does teach that the portions may be used to reassemble the 
document (p. 3, Overview para. 2, last line). Therefore it would have been obvious to repeat the 
steps until the document is sent so that the parts could be reassembled (p. 3, Overview para. 2, 
last line). 

Regarding dependent claim 34, while none of the sources disclose sending portions in order, it 
would have been obvious to do so, in order to reduce the complexity, when the data is 
reassembled (p. 3, Overview para. 2, last line). 
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Regarding dependent claim 35, Bayeh discloses gathering the data (col. 10, lines 46-58). 
Bayeh also teaches formatting data into XML syntax (col. 1 1, 11. 1-2). 
Regarding dependent claim 38, Neither Bayeh nor Heinemann discloses portions, W3C 
discloses sending a method of dividing XML in to fragments (portions) as well as sending them 
(Abstract). It would have been obvious to combine Bayeh, Heinemann and W3C in order to deal 
with portions of XML so that if the user wants a particular section, he does need to receive them 
all (W3C, p. 3, "Overview", 2^^^ para.). 

9. Claims 8, 9, 18, and 33 remain rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bayeh, Heinemann and W3C, and further in view of ^^Extensions for 
Distributed Authoring on the World Wide Web - WebDAV, Internet Draft," by Goland et 
al (published 4/7/1998), 

Regarding dependent claims 9, 18, and 33, Bayeh, W3C, and Heinemann do not disclose a 
multi-status response. Goland discloses a multi-status response, which is an ordinary XML 
document (p. 54). It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the combination of Bayeh W3C and Heinemann, which processed XML 
document as disclosed in claim 5 above, to respond with a multi-status response as it was a 
normally formatted XML document. 

Regarding dependent claim 8, Bayeh, W3C, and Heinemann do not disclose a multi-status 
response. Goland discloses a multi-status response, which is an ordinary XML document (p. 54). 
It would have been obvious to one of ordinary skill in the art at the time of the invention to use 
the combination of Bayeh W3C and Heinemann, which processed XML document as disclosed 
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in claim 5 above, to respond with a multi-status response as it was a normally formatted XML 
document. 

Neither of the sources discloses repeating the steps until the document is sent, however W3C 
does teach that the portions may be used to reassemble the document (p. 3, Overview para. 2, last 
line). Therefore it would have been obvious to repeat the steps until the document is sent so that 
the parts could be reassembled. 

While none of the sources disclose sending portions in order, it would have been obvious to do 
so, in order to reduce the complexity, when the data is reassembled (p. 3, Overview para. 2, last 
line). 

lO, Claims 20 and 30 remain rejected under 35 U.S.C. 103(a) as being unpatentable 
over Bayeh and further in view of Goland* 

Regarding independent claim 20, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Bayeh teaches gathering data for a response with an object (col. 10, lines 46-58). 

Bayeh does not disclose calling and passing data to another object that would generate 
the XML. However Bayeh does teach the data is gathered and formed by the same data servlet 
object (col. 1 1, 11. 1-2). Bayeh generates at least a portion of the response, which includes the 
whole response. It would have been obvious to one of ordinary skill in the art at the time of the 
invention to call another object to format the data, due to make the programming more modular 
in nature, which would in turn allow for greater flexibility in formats (col 2, 1. 59 - col 3, 1. 29), 
as well as allow increasing throughput (col. 8, 11. 35-63). Bayeh does not disclose the request 
being a WebDAV method. Goland discloses several WebDAV request methods (ch. 7). It 
would have been obvious to one of ordinary skill in the art at the time of the invention to request 
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XML with WebDAV as any data gathering method could be used (Bayeh, col. 10, 11 45-58). 
This obvious modification of requesting XML with WebDAV would mean that the data servlet 
object would be gathering the data required by the particular WebDAV request method. 
Therefore, upon the modification, which is suggested in within Bayeh, the data servlet object 
would be correlated to the WebDAV request method and therefore be a request method object as 
stated in the claim. 

As the methods have different functions, it would be inherent to determine what method 
is contained before processing. 

Regarding dependent claim 30, the program for performing the method of claim 20 is rejected 
under the same rationale. 

11. Claims 21-22, remain rejected under 35 U.S.C. 103(a) as being unpatentable over 

Bayeh and further in view of Goland, and further in view of Heinemann* 

Regarding dependent claim 21, Bayeh and Goland do not teach sending the XML response to 

the client; however, Bayeh teaches sending HTML because browsers at the time of Bayeh 

"expect[ed] to receive data that had been formatted with HTML." (Col. 1 1, 11, 35-43) 

Heinemann teaches that browsers at the time of the invention did expect to receive XML data (p. 

1,1'^ para, and p. 5, "Direct Viewing"). It would have been obvious to one of ordinary skill in 

the art at the time of the invention to combine Heinemann with Bayeh and send the unformatted 

XML as it would allow the client computer to use the capabilities of XML such as validation 

(Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 

Regarding dependent claim 22, Bayeh does not build an entire hierarchical tree structure. 
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12. Claims 23, 25, and 44-47 remain rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bayeh and further in view of Goland, and further in view of W3C. 
Regarding dependent claim 23, Bayeh, and Goland do not teach calling an object multiple 
times. W3C discloses sending a method of dividing XML in to fragments (portions) as well as 
sending them (Abstract). It would have been obvious to combine Bayeh and W3C in order to 
deal with portions of XML so that if the user wants a particular section, he does need to receive 
them all (W3C, p. 3, "Overview", 2"^ para.). 

W3C does teach that the portions may be used to reassemble the document (p. 3, Overview para. 
2, last line.) Therefore it would have been obvious to repeat the steps until the document is sent 
so that the parts could be reassembled (p. 3, Overview para. 2, last line). 
Regarding dependent claim 25, Bayeh, and Goland do not teach calling an object multiple 
times. W3C discloses sending a method of dividing XML in to fragments (portions) as well as 
sending them (Abstract). It would have been obvious to combine Bayeh and W3C in order to 
deal with portions of XML so that if the user wants a particular section, he does need to receive 
them all (W3C, p. 3, "Overview", 2"%ara.). 

W3C does teach that the portions may be used to reassemble the document (p. 3, Overview para. 

2, last line.) Therefore it would have been obvious to repeat the steps until the document is sent 

so that the parts could be reassembled (p. 3, Overview para. 2, last line). 

While none of the sources disclose sending portions in order, it would have been obvious to do 

so, in order to reduce the complexity, when the data is reassembled (p. 3, Overview para. 2, last 

line). 



Application/Control Number: 09/36 1 ,782 Page 14 

Art Unit: 2178 

Regarding independent claim 44, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Bayeh teaches using an object that is inherently associated with the request, and inherently 
instantiated, build the XML response (col. 10, lines 46-58, col. 1 1, 11. 1-2). 
Bayeh dos not teach HTTP verbs. Goland discloses WebDAV request methods (ch. 7). The 
office interprets these methods to be HTTP verbs. As the methods have different functions, it 
would be inherent to determine what method is contained before processing. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to request with HTTP verbs 
as any data gathering method could be used (Bayeh, col. 10, 11 45-58). This obvious 
modification of requesting XML with HTTP verbs would mean that the data servlet object would 
be gathering the data required by the particular HTTP verbs method. Therefore, upon the 
modification, which is suggested in within Bayeh, the data servlet object would be correlated to 
the HTTP verb. 

Bayeh, and Goland do not teach building portions of XML. W3C discloses sending a method of 
dividing XML in to fragments (portions) as well as sending them (Abstract). It would have been 
obvious to combine Bayeh and W3C in order to deal with portions of XML so that if the user 
wants a particular section, he does need to receive them all (W3C, p. 3, "Overview", 2^^ para.). 
Regarding dependent claim 45, Bayeh teaches that the request is routed to the "proper" object 
(col. 10, 11. 30-31). The Office interprets this to mean that the object is unique to the request. 
Regarding dependent claim 46, Bayeh discloses calling an object (servlet) and passing it the 
data (col 11,11. 20-24). 

Regarding dependent claim 47, Bayeh discloses calling an object (servlet) and passing it the 
data (col. 1 1, 11. 20-24). Bayeh also teaches formatting data into an XML syntax (col. 1 1, 11. 1- 
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2). However Bayeh does not teach formatting with the object that was passed the data. Rather 
Bay eh teaches that first it is formatted within the same object that gathered the data. It would 
have been obvious to one of ordinary skill in the art at the time of the invention to call another 
object to format the data, due to make the programming more modular in nature, which would in 
turn allow for greater flexibility in formats (col 2, 1. 59 - col 3, 1 29), as well as allow 
increasing throughput (col 8, 11 35-63), 

13. Claims 24, 26, and 41-43 remain rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bayeh, and further in view of Goland, and further in view of W3C, and 
further in view of Heinemann* 

Regarding dependent claim 24, Bayeh, and Goland do not teach sending multiple portions. 
W3C discloses a method of dividing XML in to fi-agments (portions) as well as sending them 
(Abstract). It would have been obvious to combine Bayeh and W3C in order to deal with 
portions of XML so that if the user wants a particular section, he does need to receive them all 
(W3C, p. 3, "Overview", 2^%ara.). 

W3C also teaches that the portions may be used to reassemble the document (p. 3, Overview 
para. 2, last line.) Therefore it would have been obvious send the portions so that the parts could 
be reassembled (p. 3, Overview para. 2, last line). 

Bayeh, Goland and W3C do not teach sending XML to the client but rather HTML because 
browsers at the time of Bayeh "expect[ed] to receive data that had been formatted with HTML." 
(Col. 1 1 , 11 35-43) Heinemann teaches that browsers at the time of the invention expected to 
receive XML data (p. 1,1^^ para, and p. 5, "Direct Viewing"). It would have been obvious to one 
of ordinary skill in the art at the time of the invention to combine Heinemann with Bayeh and 
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send the unformatted XML as it would allow the cHent computer to use the capabilities of XML 
such as validation (Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
Regarding dependent claim 26, Bayeh, and Goland do not teach calling an object multiple 
times. W3C discloses sending a method of dividing XML in to fragments (portions) as well as 
sending them (Abstract). It would have been obvious to combine Bayeh and W3C in order to 
deal with portions of XML so that if the user wants a particular section, he does need to receive 
them all (W3C, p. 3, "Overview", 2^^ para.). 

W3C does teach that the portions may be used to reassemble the document (p. 3, Overview para. 
2, last line.) Therefore it would have been obvious to repeat the steps until the document is sent 
so that the parts could be reassembled (p. 3, Overview para. 2, last line). 

Bayeh, and Goland do not teach sending multiple portions. W3C discloses a method of dividing 
XML in to fragments (portions) as well as sending them (Abstract). It would have been obvious 
to combine Bayeh and W3C in order to deal with portions of XML so that if the user wants a 
particular section, he does need to receive them all (W3C, p. 3, "Overview", 2^^ para.). 
W3C also teaches that the portions may be used to reassemble the document (p. 3, Overview 
para. 2, last line.) Therefore it would have been obvious send the portions so that the parts could 
be reassembled (p. 3, Overview para. 2, last line). 

Bayeh, Goland and W3C do not teach sending XML but rather HTML because browsers at the 
time of Bayeh "expect[ed] to receive data that had been formatted with HTML." (Col. 1 1, 11. 35- 
43) Heinemann teaches that browsers at the time of the invention expected to receive XML data 
(p. 1,1^^ para, and p. 5, "Direct Viewing"). It would have been obvious to one of ordinary skill 
in the art at the time of the invention to combine Heinemann with Bayeh and send the 
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unformatted XML as it would allow the client computer to use the capabilities of XML such as 
validation (Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
Regarding independent claim 41, Bayeh discloses receiving a request (col. 10, lines 19-25). 
Bayeh teaches using an object that is inherently associated with the request to gather data (col. 
10, lines 46-58), Bayeh discloses emitting formatted data (col. 1 1, 11. 20-24). However Bayeh 
does not teach formatting with the object that was passed the data. Rather Bayeh teaches that 
first it is formatted within the same object that gathered the data. It would have been obvious to 
one of ordinary skill in the art at the time of the invention to call another object to format the 
data, due to make the programming more modular in nature, -which would in turn allow for 
greater flexibility in formats (col. 2, 1. 59 - col. 3, 1. 29), as well as allow increasing throughput 
(col. 8, 11. 35-63). 

Bayeh dos not teach HTTP verbs. Goland discloses WebDAV request methods (ch. 7). 
The office interprets these methods to be HTTP verbs. As the methods have different functions, 
it would be inherent to determine what method is contained before processing. It would have 
been obvious to one of ordinary skill in the art at the time of the invention to request with HTTP 
verbs as any data gathering method could be used (Bayeh, col 10, 11 45-58). This obvious 
modification of requesting XML with HTTP verb would mean that the data servlet object would 
be gathering the data required by the particular HTTP verb. Therefore, upon the modification, 
which is suggested in within Bayeh, the data servlet object would be correlated to the HTTP 
verb. 

Bayeh, and Goland do not teach calling an object multiple times, or dealing with portions 
of XML. W3C discloses sending a method of dividing XML in to fragments (portions) as well 
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as sending them (Abstract). It would have been obvious to combine Bayeh and W3C in order to 
deal with portions of XML so that if the user wants a particular section, he does need to receive 
them all (W3C, p. 3, "Overview", 2^^^ para.). 

Bayeh, Goland and W3C do not teach sending XML to the client but rather HTML because 
browsers at the time of Bayeh "expect[ed] to receive data that had been formatted with HTML," 
(Col. 1 1, 11. 35-43) Heinemann teaches that browsers at the time of the invention expected to 
receive XML data (p. 1,1'* para, and p. 5, "Direct Viewing"). It would have been obvious to one 
of ordinary skill in the art at the time of the invention to combine Heinemann with Bayeh and 
send the unformatted XML as it would allow the client computer to use the capabilities of XML 
such as validation (Heinemann, p. 2), DOM, (Heinemann, p. 3), and XSL (Heinemann, p. 4). 
Regarding dependent claim 42, while none of the sources disclose sending portions in order, it 
would have been obvious to do so, in order to reduce the complexity, when the data is 
reassembled (p. 3, Overview para. 2, last line). 

Regarding dependent claim 43, Bayeh, Goland and W3C, are silent as to sending less then an 
entirety of a response. However, it would have been obvious to one of ordinary skill in the art to 
send less the entirety of the response so that if the user wants a particular section, he does need to 
receive them all (W3C, p. 3, "Overview", 2''^ para.). 

14, Claims 12, 15, 36, 39, and 40 remain rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bayeh, Heinemann, and W3C, and further in view of Kavner (USPN 
6366947— filed on 1/20/1998). 

Regarding dependent claims 12, 36, and 39 Bayeh, Heinemann and W3C are silent as to using 
a buffer. Kavner discloses a buffer that buffers a response until it is filled, and then empties, or 
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sends the buffer to the cHent (col 10, lines 7-14). There inherently must be a threshold in order 
for the buffer to be full. It would have been obvious to one of ordinary skill in the art to modify 
Kavner into Bayeh and Schloss in order to buffer the response. 

Regarding dependent claim 40, Bayeh, Heinemann, W3C, and Kavner are silent as to sending 
less then an entirety of a response. However, it would have been obvious to one of ordinary skill 
in the art to send less the entirety of the response so that if the user wants a particular section, he 
does need to receive them all (W3C, p. 3, "Overview", para.). 

Regarding dependent claim 15, Bayeh, Heinemann and W3C are silent as to using a buffer. 
Kavner discloses a buffer that buffers a response until it is filled, and then empties, or sends the 
buffer to the client (col. 10, lines 7-14). There inherently must be a threshold in order for the 
buffer to be full It would have been obvious to one of ordinary skill in the art to modify Kavner 
into Bayeh in order to buffer the response. 

15. Claims 27-29 remain rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bayeh, and Goland, and further in view of W3C, and further in view of Kavner. 
Regarding dependent claim 27, Bayeh and Goland do not discloses multiple portions. W3C 
discloses sending a method of dividing XML in to fragments (portions) as well as sending them 
(Abstract). It would have been obvious to combine Bayeh and W3C in order to deal with 
portions of XML so that if the user wants a particular section, he does need to receive them all 
(W3C, p. 3, "Overview", l""^ para.). 

Bayeh, Goland and W3C are silent as to using a buffer. Kavner discloses a buffer that buffers a 
response until it is filled, and then empties, or sends the buffer to the client (col. 10, lines 7-14). 
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It would have been obvious to one of ordinary skill in the art to modify Kavner into Bayeh, 
Go land and W3C in order to buffer the response. 

Regarding dependent claims 28, Bayeh, Goland and W3C, and Kavner are silent as to sending 
less then an entirety of a response. However, it would have been obvious to one of ordinary skill 
in the art to send less the entirety of the response so that if the user wants a particular section, he 
does need to receive them all (W3C, p. 3, "Overview", 2""^ para.). 
Regarding dependent claims 29, the buffer disclosed in Kavner must inherently have a 
threshold in order for the buffer to be full. 

Response to Arguments 
16. Applicant's arguments filed 1 1/3/2003 have been fully considered but they are not 
persuasive. 

Regarding Applicant's remarks on Claim 1: 

Applicant alleges that the Office fails to make prima facie case for obviousness due to Bayeh 
allegedly teaching several optimizations that teach away from the rejections laid out by the 
Office. The Office disagrees for several reasons. Applicant argues that the modifications 
eliminate the need for the rendering servlet. Assuming that the Office intended to eliminate the 
rendering servlet, despite Bayeh using rendering servlet to create HTML, Bayeh generally 
discloses an XSL style-sheet processor (col. 9, 11. 4-7). Such a style-sheet processor easily can 
produce XML. Furthermore as the Bayeh uses this to create the XML, though not explicitly 
disclosed, due to the nature of XSL transforms, the HTML created is most likely XHML, an 
application of XML. Still assuming the rendering servlet would be eliminated, the optimizations 
Applicant has referenced are optimizations for reducing the bottleneck cause by the rendering 
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servlet, hence the servlets absence would also negate the usefulness of these optimizations. 
These optimizations are more a discussion of the basic servlet paradigm. Despite Bayeh 
discussing both the data and rendering servlet they can be applied to any servlet. 
Applicant also alleges that W3C teaches away from the invention, because it supports only 
receiving part of a document. However, the Office clearly cited in the previous rejection: 

. . W3C does teach that the portions may be used to reassemble the document (p. 3, Overview 
para. 2, last line.) Therefore it would have been obvious to repeat the steps until the document is 
sent so that the parts could be reassembled (p. 3, Overview para. 2, last line)." As seen in the 
cited portions W3C teaches multiple uses for the fragment technology. 
Regarding Applicant's remarks on Claims 2-4: 

As Applicant has relied on the alleged deficiencies of the rejection of claim 1 to traverse the 
rejections of claims 2-4, and as those deficiencies have been addressed above, the claims remain 
rejected under the same rationale. 
Regarding Applicant's remarks on Claim 5: 

Applicant argues that Bayeh and Heinemann are not combinable. The Office submits that this 
argument has been addressed in the discussion of claim 1 above. 

Applicant also alleges that W3C teaches away from the subject mater of claim 5. The Office 
disagrees. AppUcant says, "... if one considers what the W3C user asks for as 'an XML 
document', then it is clear that W3C does not teach sending only a portion of chapter 20 to the 
client." The Office disagrees with the assumption that Applicant has made, and further in no 
way has suggested that W3C is talking about sending part of chapter 20 to anybody. As evident 
in the entirety of the W3C document, the document is related to obtaining a portion of a larger 
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XML document. Furthermore, Applicant has not shown any other cause within the document to 
suggest such an interpretation of the document. 
Regarding Applicant's remarks on Claims 6-13: 

As Applicant has rehed on the alleged deficiencies of the rejection of claim 5 to traverse the 
rejections of claims 6-13, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 
Regarding Applicant's remarks on Claim 14: 

Applicant alleges that Bayeh does not teach receiving a request. The cited portion does in fact 
recite a "search request." As shown in Fig, 5, and at col. 10, 11. 46-57, this is in fact a request for 
XML. The Applicant alleges that there is no suggestion for sending XML rather then XML. 
The Office has addressed these arguments in the discussion of claim 1 above. 
In regard to the obviousness of the gathering and formatting by different objects, such a 
modification would have been obvious to one of ordinary skill in the art at the time of the 
invention to call another object to format the data, due to Bayeh' s teachings of making the 
programming more modular in nature, which would in turn allow for greater flexibility in 
formats (col. 2, 1. 59 - col. 3, 1. 29), as well as allow increasing throughput (col. 8, 11. 35-63). 
In regard to the negative limitation "without building a hierarchical tree," the Office disagrees 
with Applicant. First of all the Office disagrees that it is the Office's responsibility to 
specifically point out where a reference teaches a negative limitation. The fact that none of the 
sources address this need proves the teaching. Secondly, that W3C teaches fragmenting a 
document means, regardless of whether or not a tree is built, that the alleged tree would not 
represent the XML response requested in the claim language. Finally, the Office knows of at 
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least two ways to represent an XML document: As text characters, and as a DOM tree. If a 
source does not say how the document is represented, the Office interprets this as not requiring a 
tree to be built. Furthermore, as Bayeh specifically discloses a stream, as Applicant points out, it 
still does not build a tree. 

Regarding Applicant's remarks on Claims 15-19: 

As Applicant has reUed on the alleged deficiencies of the rejection of claim 14 to traverse the 
rejections of claiml5-19, and as those deficiencies have been addressed above, the claims remain 
rejected under the same rationale. 
Regarding Applicant's remarks on Claim 20: 

Applicant alleges that the Office's modification has no effect. The Office disagrees. This 
obvious modification of requesting XML with WebDAV would mean that the data servlet object 
would be gathering the data required by the particular WebDAV request method. Therefore, 
upon the modification, which is suggested in within Bayeh, the data servlet object would be 
correlated to the WebDAV request method and therefore be a request method object as stated in 
the claim. 

Regarding Applicant's remarks on Claims 21-30: 

As Applicant has relied on the alleged deficiencies of the rejection of claim 20 to traverse the 
rejections of claims 21-30, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 
Regarding Applicant's remarks on Claim 31: 

The Applicant alleges that there is no suggestion for sending XML rather then XML. The Office 
has addressed these arguments in the discussion of claim 1 above. 
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Applicant alleges that there is a difference between a less then an entirety of a response and an 
entirety of a document. The Office disagrees. This would depend on what the request is for. As 
W3C states, the fi^agment format has many applications, such as collection for reassembly (p. 5, 
para. 1), which would constitute the fi*agment being a portion of a response. 
Regarding Applicant's remarks on Claims 32-36: 

As Applicant has relied on the alleged deficiencies of the rejection of claim 3 1 to traverse the 
rejections of claims 32-36, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 
Regarding Applicant's remarks on claim 37: 

Applicant alleges Bayeh does not disclose multiple calls. The Office disagrees. Bayeh also 
teaches that multiple servlets may call multiple servlets (col. 8, 11. 43-45). Bayeh does not 
explicitly disclose to a pre-defined order of calls. It would have been obvious to one of ordinary 
skill in the art at the time of the invention to call these servlets in a predefined order, as the XML 
documents would be in a predefined linear order. 
Regarding Applicant's remarks on Claims 38-40: 

As Applicant has reKed on the alleged deficiencies of the rejection of claim 37 to traverse the 
rejections of claims 38-40, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 
Regarding Applicant's remarks on Claim 41: 

Applicant's alleges that the cited art does not suggest instantiating a request object that 
corresponds to an http verb. The Office disagrees. This obvious modification of requesting 
XML with HTTP verbs would mean that the data servlet object would be gathering the data 
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required by the particular HTTP verbs method. Therefore, upon the modification, which is 
suggested in within Bayeh, the data servlet object would be correlated to the HTTP verb. 
Regarding Applicant's remarks on Claims 42-43: 

As Applicant has relied on the alleged deficiencies of the rejection of claim 41 to traverse the 
rejections of claims 42-43, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 
Regarding Applicant's remarks on Claim 44: 

Applicant's remarks on claim 44 have been addressed in the comments on claim 41 above. 
Regarding Applicant's remarks on Claims 45-47: 

As Applicant has relied on the alleged deficiencies of the rejection of claim 44to traverse the 
rejections of claims 45-47, and as those deficiencies have been addressed above, the claims 
remain rejected under the same rationale. 

Conclusion 

17. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event. 
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however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

18. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Adam M Queler whose telephone number is (703) 308-5213. 
The examiner can normally be reached on Monday-Friday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor. Heather R Hemdon can be reached on (703) 308-5186. The fax phone number for 
the organization where this appUcation or proceeding is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703) 306-563 1 . 
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